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Method for a secure hand- 
shake protocol between A and B, 
connected by a slow channel (Urn). 
A sends a first message (21) indi- 
cating a set of cipher suites with 
parameters, and its identifier (IDa). 
B selects a cipher suite, obtains 
A*s certificate (Ca) over a fast 
connection, verifies A's certificate 
(Ca) and obtains A's public key 
(Ea). Next B sends a second mes- 
sage (26) comprising B*s certificate 
(Cb), and indication that B has ver- 
ified A's certificate (Ca), and an in- 
dication about the selected cipher 
suite. A begins to use the selected 
cipher suite, verifies B's certificate 
(Cb) and obtains B's public key 
(Eb). Next A sends a third mes- 
sage (28) indicating that A has ver- 
ified B's certificate (Cb). Applica- 
tion data can be sent from A to B 
in the third message (28). whereby 
a two-way key-exchange and mu- 
tual verification is achieved with an 
effective overhead of two messages 
(21, 26) between A and B. 
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Secure handshake protocol 

Background of the Invention 

The present invention relates in general to a secure handshake 
protocol for telecommunications networks. More particularly, the invention re- 
5 lates to a method and an apparatus for providing secure handshake between 
call parties with minimal overhead before actual data transmission. 

Within this application, "TLS" refers to Transport Layer Security. 
One such protocol is described in "The TLS Protocol", May 21, 1997, by Tim 
Dierks and Christopher Allen, Consensus Development This document has 
10 been published as "draft-ietf-tls-protocol-03.txt", incorporated herein by refer- 
ence. More particularly, the present invention proposes an improved hand- 
shake protocol which is applicable La. in protocols like TLS. 

A TLS-type protocol comprises several layers, such as: 

Upper layer protocols 
15 Handshake protocol/Alert protocol/Application protocol 

Record protocol 

Transport protocol 

Lower level protocols 

Figure 1 is based on section 7.3 of said TLS draft protocol, and it 

20 illustrates a prior art handshake method. In order to keep the specification 
consistent with said draft, parties A and B are also referred to as "client" and 
"server", respectively. (Terms like "hello" and "finished" are also used consis- 
tently with said TLS draft.) In step 1 1 , the client A sends a client hello mes- 
sage. This client hello message comprises a list of cipher suites and compres- 

25 sion methods supported by the client. Additionally, the message may also 
comprise a time stamp. In step 12, the server B selects a cipher suite and a 
compression method. (Optionally, B may also check the timestamp to make 
sure that the message is not an old message being retransmitted.) 

In step 13 the server B responds with a server hello message. The 

30 client hello and server hello messages 11 and 13 establish security between 
the parties, typically by establishing the following attributes: protocol version, 
session ID, cipher suite and compression method. In connection with the 
server hello message, the server B sends its own certificate C B to the client A 
and it requests the client A to send its client certificate C A to the server B. In 

35 response to this, in step 14 the client A verifies B's certificate and obtains B's 
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public key E B . In step 15 the client A sends B a finished message, indicating 
that A has been able to verify B's identity. Additionally, A sends its own certifi- 
cate C A to B. In step 16, B uses C A to obtain A's public key E A . In step 17, B 
sends its own finished message to the client A. In connection with verifying its 
5 peer's identity, each party independently calculates a shared secret key for 
this session. Now both parties have exchanged keys, agreed on a cipher 
suite/compression method and verified the identity of the other party. In step 
18, the client A can start transmitting application data. 

An essential component in the above protocol are the certificates C A 

10 and C B . By means of certificates signed by a mutually trusted authority, each 
party can verify its peer's identity. A certificate comprises at least its owner's 
identity (A/B) and public key(s) (E A /E B ), period of validity, the issuer of the cer- 
tificate and the issuer's digital signature. It may also comprise the rights 
granted to its owner. A suitable mechanism for digital signatures is a reversal 

15 of public-key encryption: the issuer signs the certificate withjts private key and 
whoever wants to verify the certificate, does so by using the issuer's public 
key. A suitable structure for a certificate is specified in ISO standard X.509. 

A problem with this prior art handshake protocol is the high over- 
head required. As seen in Fig. 1, the actual data transmission does not begin 

20 until step 15, or after four messages have been transmitted between the par- 
ties. In a wireless multiple access system, where the parties A and B are sepa- 
rated by an air interface Urn and a public land based mobile network PLMN, 
the actual messaging is much more complicated than the one shown in Fig. 1. 
This is because Fig. 1 only shows the actual messages and omits (for clarity) 

25 the resource reservation and release steps which are routine for a person 
skilled in the art, but which are nevertheless indispensable. 

Disclosure of the Invention 

Based on the foregoing description, it is an object of the present in- 
vention to create a method and suitable network elements (nodes and termi- 

30 nals) for providing a secure handshake protocol with a low overhead, i.e. a 
small number of messages over the air interface. This object will be achieved 
with a method and network elements which are characterized by what is dis- 
closed in the appended independent claims. Advantageous embodiments of 
the present invention will be presented in the dependent claims. 

35 The invention is based on a novel distribution of operations be- 

tween the parties A and B. In addition, some messages over the air interface 
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can be eliminated by using a land-based certificate store or service, and per- 
forming an inquiry to this store. Further, the invention is based on the vision 
that the last message of the handshake proper should be sent from A to B, 
whereby actual data transmission can be concatenated with the last hand- 
5 shake message, whereby the net overhead is minimised. 

The invention is applicable to telecommunication systems with a 
slow and/or unreliable transmission channel acting as a bottleneck between 
the parties. 

Brief Description of the drawings 

10 In the following, the invention will be described by means of pre- 

ferred embodiments with reference to the accompanying drawing, in which: 

Figure 1 shows a signalling diagram illustrating a prior art hand- 
shake protocol; and 

Figure 2 is a combination wherein the bottom portion is an inter- 
15 leaved signalling diagram/flowchart illustrating an embodiment of the invention 
and the top portion is a block diagram showing how the inventive functionality 
can be mapped to various network elements. 

Detailed description of the invention 

Referring now to Fig. 2, an embodiment of the invention will be de- 

20 scribed. The lower portion of Fig. 2 is an interleaved signalling dia- 
gram/flowchart illustrating an embodiment of the invention. The upper portion 
of Fig. 2 is an associated block diagram, illustrating a possible mapping be- 
tween call parties and physical network elements. 

In step 21 the client A sends a first inter-party message comprising 

25 all the elements of the message of step 11. (An inter-party message is a mes- 
sage from A to B or vice versa.) Additionally, the message of step 21 com- 
prises an identifier ID A of the client A, and encryption parameters (such as 
random numbers and/or initialisation vectors) if required by any of the indi- 
cated cipher suites. The identifier ID A will be studied later in more detail. In re- 

30 sponse to the client hello message, in step 22 the server B selects a cipher 
suite. Preferably, it also checks the timestamp of the message sent by A. In 
step 23, instead of requesting A's certificate C A from A itself, the server B uses 
the ID A sent by A to retrieve A's certificate C A from a certificate store CS. The 
connection between B and CS should be significantly faster than the air inter- 

35 face Um. In step 24, the trustee CS returns A's certificate C A . Alternatively or 
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additionally, B can also maintain a local memory MEM of certificates and omit 
the inquiry to CS if A's certificate is found in the local memory. In step 25, B 
verifies C A , obtains A's public key E A and calculates the shared secret key. In 
step 26, B sends a second inter-party message to A. The second inter-party 

5 message comprises B's certificate C B . It also indicates that B has been able to 
verify A's certificate. (However, this indication can be an implicit one, meaning 
that B only sends its certificate if it has verified As certificate.) In step 27, A 
verifies B's certificate C B , obtains B's public key E B and calculates the shared 
secret key. In step 28, A sends B a third inter-party message comprising a fin- 

10 ished message which indicates that it has been able to verify B's certificate. 

For clarity, Fig. 2 only shows what happens when the handshake is 
successful, i.e. both parties act according to the protocol. If a departure from 
the protocol is detected, this is usually a fatal error and the handshake termi- 
nates. 

15 It should be noted that the last inter-party message (comprising the 

finished message in step 28) points from A to B. This is in marked contrast to 
the prior art handshake shown in Fig. 1. An advantage of this property of the 
invention is that application data can be concatenated with the third inter-party 
message in step 28. Thus the effective overhead of the handshake protocol 

20 according to the invention is only two inter-party messages, compared to an 
overhead of four messages in the prior art handshake. In order to achieve this, 
an appropriate key exchange mechanism must be used. Suitable key ex- 
change algorithms include Diffie-Hellman (DH) with fixed parameters certified 
with Digital Signature Algorithm (DSA). The DH algorithm can be found in most 

25 textbooks on cryptography. Additionally, the original Diffie-Hellman algorithm 
(DH) is described in US Patent 4 200 770 and the Digital Signature Algorithm 
(DSA) is a U.S. standard and a de facto international standard. Another good 
combination is Elliptic Curve Diffie-Hellman (ECDH) with fixed parameters cer- 
tified with Elliptic Curve Digital Signature Algorithm (ECDSA). The difference 

30 between standard DH and ECDH is only different mathematics in obtaining 
and using encryption and decryption keys. Such differences are not essential 
to the invention. 

Additionally, RSA (Rivest-Shamir-Adlemann) and ECES (Elliptic 
Curve Encryption Scheme) algorithms can be used with appropriate modifica- 
35 tions. With these algorithms, a server key exchange takes place as follows. B 
generates a random number, which is a pre-master secret, encrypts it with A's 
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public key, and sends the result to A. Thus the message in step 26 would 
comprise ServerHello, C B , ServerKeyExchange, Finished. Now A decrypts this 
pre-master secret. This server key exchange procedure resembles a mirror 
image of the one used in TLS, whereby the handshake can still be accom- 

5 plished with two messages over the air interface. 

The handshake method described above uses public keys. As is 
well known, public-key cryptography is much slower than symmetric cryptog- 
raphy. Therefore, it is preferable to use the public-key handshake only for ex- 
changing parameters which are used for computing a shared key for symmet- 

10 ric cryptography, such as DES. The parameters (random numbers) sent in 
message 21 can be used for this purpose. 

Although the inventive handshake somewhat limits the available 
key-exchange mechanisms during the handshake phase, the invention does 
not limit the available mechanisms used for the actual data transmission. In 

15 other words, the invention does not limit the choices available for symmetric 
cryptography, although it requires that the parameters for the symmetric cryp- 
tography first used are exchanged by using a key-exchange mechanism with 
fixed parameters. The encryption parameters sent in message 21 (and 26) can 
be combined with private keys to create pre-master secrets which in turn are 

20 used to create master secrets, etc. Thus, to each application data message 
following message 28, a separate message can be concatenated. This sepa- 
rate message can be used for changing the selected cryptography mecha- 
nism. 

The identifier ID A of client A should be unique to each A. Suitable 
25 identifiers are e.g. a network number, such as MSISDN or an X.509 number. 
The ID A is not protected by the handshake protocol proper, although it may be 
protected by a lower level protocol. Therefore, it is preferable to create the ID A 
using a one-way function, such as a hash function. One-way functions are 
functions that are much easier (at least by several orders of magnitude) to 
30 perform in one direction than in the reverse direction. Examples of one-way 
functions are multiplying large prime numbers, discrete exponentiation, ellipti- 
cal functions and hash functions. The advantage of one-way functions is that 
they hide the identity of A from possible eavesdroppers. As is well known, 
hash functions reduce information. Hashed numbers are thus not necessarily 
35 unique. However, a good combination is achieved by using a hash of the cli- 
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ent's public key E A and assigning public keys such that they do not produce 
identical hash values. 

The upper portion of Fig. 2 shows how the functionality of the in- 
vention can be mapped to various network elements. The invention can be 

5 used in a wireless communication system, such as a mobile communications 
system. The client A can be a mobile station MS, possibly having a portable 
computer PC connected or integrated thereto. The server B can be a com- 
puter B' providing financial services, or granting access to confidential infor- 
mation, etc. A and B can communicate over an air interface Um and via a pub- 

10 lie land based mobile network PLMN, possibly also via a public switched mo- 
bile network PSTN. 

The trustee CS could be implemented in one of the registers of the 
PLMN, such as a home location register (HLR), or a GPRS register GR. Alter- 
natively, the trustee services can be implemented as disclosed in said ISO 

15 standard X.509. 

Instead of retrieving A's certificate from CS, or in addition to it, B 
can maintain a local memory MEM of certificates and omit the inquiry to CS if 
A's certificate is found in the local memory. B can e.g. be connected to a local 
area network and the certificates of all the clients A are maintained over the 

20 local area network. A local memory MEM can also be used as a cache mem- 
ory for storing recently used certificates. In real-time applications, if a certifi- 
cate is revoked, the computer B' must be informed and it must also delete the 
revoked certificate from its cache. 

An important advantage of the invention is that the overhead over 

25 the slow communications channel, such as the air interface, can be halved 
compared to prior art protocols. Another advantage is that the client's certifi- 
cate C A does not have to stored in the client itself. Since the client A is typically 
a mobile station, its memory capacity is limited. This also reduces the informa- 
tion gained by dishonest third parties in case the client hardware gets lost or 

30 stolen, or is used by unauthorised persons. Also, because the client's certifi- 
cate C A is not transmitted over the air interface, less information is leaked to 
possible eavesdroppers. 

The invention has been described in its preferred embodiments. 
However, the specifications for telecommunications technology are developing 
35 rapidly. Such developments may require additional modifications to the inven- 
tion. Therefore, all words and expressions should be interpreted broadly, and 



WO 99/25093 PCT/FI98/00869 

7 

they are intended for illustrating rather than limiting the invention as specified 
in the appended claims. 
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Claims: 

1. A method for a secure handshake protocol between a first party 

(A) and a second party (B), connected via a communications channel (Urn, 
PLMN) wherein each party supports a respective set of cipher suites and for 

5 each party, a respective certificate (C A , C B ) is defined, each of the certificates 
(C A , C B ) comprising a public key (E A , E B ) of its respective owner (A, B); the 
method being characterized in that 

the first party (A) sends a first inter-party message (21) indicating 
the set of cipher suites supported by it, parameters required by the cipher 
10 suites, and an identifier (1D A ) of the first party (A); 

in response to the first inter-party message (21), the second party 

(B) : 

- selects one of said indicated cipher suites which is also supported 
by the second party (B); 

16 - uses said identifier (IDa) to obtain the certificate (C A ) of the first 

party (A) over a connection which is significantly faster than the communica- 
tions channel (Urn, PLMN) connecting said parties; 

- verifies said obtained certificate (C A ) the of the first party (A) and 
obtains the public key (E A ) of the first party (A); 

20 - sends a second inter-party message (26) comprising the certificate 

(C B ) of the second party (B), an indication that the second party (B) has veri- 
fied the certificate (C A ) of the first party (A), and an indication about said se- 
lected cipher suite; 

in response to the second inter-party message (26), the first party 

25 (A): 

- begins to use the selected cipher suite; 

- verifies the certificate (C B ) of the second party (B) and obtains the 
public key (E B ) of the second party (B); 

- sends a third inter-party message (28) indicating that the first party 
30 (A) has verified the certificate (C B ) of the second party (B); 

whereby information not needed for the above steps can be sent 
from the first party (A) to the second party (B) in the third inter-party message 
(28), thus providing a two-way key-exchange and mutual verification with an 
effective overhead of two inter-party messages (21, 26). 
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2. A method according to claim 1, characterized in that said 
step of obtaining the certificate (C A ) of the first party (A) comprises retrieving it 
from a source (CS) external to the second party. 

3. A method according to claim 2, characterized in that said 
5 external source (CS) is a register (HLR, GR) of a telecommunications network 

or a directory service substantially conforming to ISO standard X.509. 

4. A method according to claim 1, characterized in that said 
step of obtaining the certificate (C A ) of the first party (A) comprises retrieving it 
from a local memory (MEM). 

10 5. A method according to any one of the preceding claims, char- 

acterized in that said identifier (IDa) of the first party (A) is formed by 
means of a one-way function, preferably a hash function. 

6. A method according to any one of the preceding claims, char- 
acterized in that said second inter-party message (26) comprises a pre- 

15 master secret which the second party (B) obtains by generating a random 
number and encrypting it with the public key (E A ) of the first party (A). 

7. A telecommunications apparatus (A) being adapted to act as a 
first party in a secure handshake protocol between said apparatus (A) and a 
second party (B), said apparatus being characterized in that it is 

20 adapted to: 

- send a first message (21) to the second party (B), said first mes- 
sage indicating a set of cipher suites, parameters required by said cipher 
suites, and an identifier (IDJ of the apparatus (A); 

- receive a second message (26) from the second party (B), said 
25 second message comprising an indication about a cipher suite selected by 

said second party, a certificate (C B ) of the second party, an indication that the 
second party (B) has used said identifier (ID A ) of the apparatus to obtain and 
verify a certificate (C A ) of the apparatus (A), and; 

- use the cipher suite indicated by said second message (26); 

30 - verify the certificate (C B ) of the second party (B) and obtain a pub- 

lic key (E B ) of the second party (B); 
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- send a third message (28) to the second party (B), said third mes- 
sage indicating that the apparatus (A) has verified the certificate (C B ) of the 
second party. 

8. A telecommunications apparatus (A) according to claim 7, 
5 characterized by being adapted to insert information not needed for the 

above operations in said third message (28). 

9. A telecommunications apparatus (B) being adapted to respond to 
a secure handshake protocol initiated by a first party (A), said apparatus (B) 
being connectable to said first party (A) by a communications channel (Urn, 

10 PLMN), said apparatus (B) being characterized in that it is adapted to: 

- receive a first message (21) from the first party (A), said first mes- 
sage indicating a set of cipher suites, parameters required by the cipher 
suites, and an identifier (1D A ) of the first party (A); 

- select one of said indicated cipher suites; 

15 - use the identifier (ID*) to obtain a certificate (C A ) of the first party 

(A) over a connection which is significantly faster than said communications 
channel (Urn, PLMN); 

- verify said obtained certificate (Ca) of the first party (A) and obtain 
a public key (E A ) of the first party (A); 

20 - send a second message (26) to the first party (A), said second 

message comprising a certificate (C B ) of the apparatus (B), indicating that the 
apparatus (B) has verified the certificate (C A ) of the first party (A), and indicat- 
ing said selected cipher suite; 

- receive a third message (28) from the first party (A), said third 
25 message indicating that the first party (A) has verified the certificate (C B ) of the 

apparatus (B). 

10. A telecommunications apparatus (B) according to claim 9, 
characterized by being adapted to extract information not needed for 

. the above operations from said third message (28). 
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